Continuous data protection and remote block-level storage for a data volume

ABSTRACT

A system and method for writing and reading blocks of a data volume are disclosed. The method provides continuous data protection (CDP) for a data volume by backing up blocks of the data volume in real time to a local CDP log and transmitting the blocks over the Internet for storage in a remote CDP log on a server computer system in response to write requests that change the blocks of the data volume. In response to a read request for a particular block the method attempts to read the block from the data volume. If the block is not present in the data volume the method attempts to read the block from the local CDP log. If the block is not present in the local CDP log the method request the server computer system to read the block from the remote CDP log and return the block.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to reading and writing blocks of a data volume.More particularly, the invention relates to a system and method forproviding continuous data protection (CDP) for a data volume by backingup blocks of the data volume in real time to a local CDP log andtransmitting the blocks over the Internet for storage in a remote CDPlog on a server computer system in response to write requests thatchange the blocks of the data volume.

2. Description of the Related Art

Computer systems often employ backup solutions to backup data in orderto protect it against hardware failure or data corruption. Some backupsolutions work by periodically performing backups at scheduled timeintervals. For example, the data may be backed up daily or weekly. Ifthe backup data is needed then the user can select one of the backupimages that were created, and the data it contains can be restored tothe computer system.

One problem with performing periodic backups in this manner is that anydata that was changed since the time the most recent backup wasperformed will be lost in the event of a disk failure or other disaster.Also, in some cases the user may need the ability to restore the data toa particular point in time with more specificity than allowed by thetime intervals at which the backups are performed. For example, thebackup software may perform daily backups, but the user may need torestore the data to the state as it existed at a particular time withina certain day.

These problems have been addressed by backup and restore software whichprovides continuous data protection (CDP). In a CDP solution there areno backup schedules. Instead, the data is continuously backed up in realtime as the data is changed. For example, continuous data protection maybe provided for a data volume at the block level. Each time a block inthe volume is changed, a copy of the block may be copied into a CDP log,along with a timestamp indicating the current time. Thus, for any givenblock in the volume, there may be multiple copies of the block in theCDP log, where each copy corresponds to one of the times when the blockwas changed. Since the data is continuously backed up, the CDP log canbe used to restore the volume to its state as it existed at virtuallyany specified point in time by using the timestamp information in theCDP log to find the appropriate copy of each respective block of thevolume, e.g., the copy which represents the state of the respectiveblock at the specified point in time.

SUMMARY

Various embodiments of a system and method for reading and/or writingblocks of a data volume are disclosed herein. According to oneembodiment of the method, a first request to read a particular block ofthe data volume may be received. In response to the first request, themethod may operate to attempt to read the particular block from the datavolume. In response to determining that the particular block is notpresent in the data volume, the method may operate to attempt to readthe particular block from a first continuous data protection (CDP) logfor the data volume. In response to determining that the particularblock is not present in the first CDP log, a second request for theparticular block may be sent over a network to a server computer system.The particular block may then be received from the server computersystem.

A further embodiment of the method may comprise receiving a thirdrequest to write the particular block to the data volume. In response tothe third request, the particular block may be stored in the datavolume. The particular block may also be stored in the first CDP log forthe data volume. The particular block may also be transmitted over thenetwork for storage on the server computer system.

According to one particular embodiment, the system may include a firstcomputer system and a second computer system. The first computer systemand the second computer system may each be coupled to a server computersystem. The first computer system may be configured to receive a writerequest to write a particular block to a data volume. In response to thewrite request, the first computer system may store the particular blockin a first copy of the data volume. The first computer system may alsostore the particular block in a first continuous data protection (CDP)log for the first copy of the data volume. The first computer system mayalso transmit the particular block over a network for storage on theserver computer system.

The second computer system may be configured to receive a read requestto read the particular block of the data volume. In response to the readrequest, the second computer system may attempt to read the particularblock from a second copy of the data volume. In response to determiningthat the particular block is not present in the second copy of the datavolume, the second computer system may attempt to read the particularblock from a second CDP log for the second copy of the data volume. Inresponse to determining that the particular block is not present in thesecond CDP log, the second computer system may send a request for theparticular block to the server computer system. The second computersystem may then receive the particular block from the server computersystem.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the invention can be obtained when thefollowing detailed description is considered in conjunction with thefollowing drawings, in which:

FIG. 1 illustrates one embodiment of a system for reading and writingblocks of a data volume;

FIG. 2 is a flowchart diagram illustrating one embodiment of a methodfor writing to the data volume;

FIG. 3 is a flowchart diagram illustrating one embodiment of a methodfor reading from the data volume;

FIG. 4 illustrates an embodiment in which the system includes a firstlocal host computer system and a second local host computer system,where a copy of a data volume maintained by the first local hostcomputer system is created on the second local host computer system;

FIG. 5 illustrates an example of a local host computer system accordingto one embodiment; and

FIG. 6 illustrates an example of a server computer system according toone embodiment.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and are described in detail. It should beunderstood, however, that the drawings and detailed description theretoare not intended to limit the invention to the particular formdisclosed, but on the contrary, the intention is to cover allmodifications, equivalents and alternatives falling within the spiritand scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION

Various embodiments of a system and method for reading and writingblocks of a data volume are disclosed herein. FIG. 1 illustrates oneembodiment of the system. The system includes a local host computersystem 82 which manages a data volume 300. The data volume 300 is storedon one or more storage devices, such as one or more storage devices125A. In various embodiments, the storage device(s) 125A may be coupledto the local host computer system 82 in any of various ways, asdescribed below with reference to FIG. 5.

The data volume 300 corresponds to a partitioning and/or aggregation ofphysical storage provided by one or more storage devices including, butnot limited to, single storage devices (e.g., disk drives), storagesystems such as RAID (Redundant Array of Independent Disks) systems,disk arrays, JBODs (Just a Bunch Of Disks, used to refer to disks thatare not configured according to RAID), tape devices, and optical storagedevices. The data volume 300 may be formed from a portion of the overallstorage of a physical device, from the storage of an entire physicaldevice, or from the storage of multiple physical storage devicescombined. The data volume 300 includes a plurality of units of datacalled blocks. In some embodiments the blocks may be equally sized. Invarious embodiments the blocks may have any size, e.g., may include anynumber of bytes.

The data volume 300 may be created and managed by software executing onthe local host computer system 82, referred to herein as volumemanagement and backup software 205. In particular, the volume managementand backup software 205 may handle read and write requests received fromapplications executing on the local host computer system 82 in order toread blocks from and write blocks to the data volume 300. For example,in response to a write request to write one or more blocks, the volumemanagement and backup software 205 may write the specified block(s) tothe data volume 300. Similarly, in response to a read request to readone or more blocks from the data volume 300, the volume management andbackup software 205 may read the specified block(s) from the data volume300.

In addition, the volume management and backup software 205 may alsocreate and maintain a local continuous data protection (CDP) log 302Afor the data volume 300. The local CDP log 302A includes block-levelinformation useable to restore the data volume 300 to a specified pointin time. The volume management and backup software 205 may use anyconventional CDP techniques known in the art to store information in thelocal CDP log 302A. In particular, the volume management and backupsoftware 205 may store change information in the local CDP log 302Aindicating changes to blocks in the data volume 300, where the changeinformation is stored in the local CDP log 302A in real time as theblocks are changed. For example, each time the volume management andbackup software 205 writes to a block of the data volume 300, the volumemanagement and backup software 205 may copy the new data for the blockinto the local CDP log 302A. The volume management and backup software205 may also store a timestamp in the local CDP log 302A indicating thetime at which the block was changed. The block data and timestampinformation may be stored in the local CDP log 302A in real time inresponse to the write request, e.g., such that the block data andtimestamp information is stored in the local CDP log 302A immediatelyafter or very soon after the block data is stored in the data volume300.

Thus, in some embodiments, if a failure of the data volume 300 occurs,the information in the local CDP log 302A may be used to restore thedata volume 300 to its state as it existed at the moment just prior tothe failure. The information in the local CDP log 302A may also be usedto restore the data volume 300 to its state as it existed at a specifiedpoint in time in the past. For example, even if there are no errors inthe data volume 300, it may be desirable to restore the data volume 300to a previous time point, e.g., for data mining or other purposes.

Each time a block of the data volume 300 is changed, a new copy of theblock corresponding to the change may be added to the local CDP log302A, along with a timestamp indicating the current time. Thus, for anygiven block in the data volume 300, there may be multiple copies of theblock in the local CDP log 302A, where each copy corresponds to one ofthe times when the block was changed. In a restore operation, a user mayspecify a desired time, and the volume management and backup software205 may use the timestamp information stored in the local CDP log 302Ato restore the data volume 300 to its state as it existed at thespecified time, e.g., by using the timestamp information to select theappropriate copies of each block of the data volume 300 from the localCDP log 302A.

In some embodiments the local CDP log 302A may be stored on a differentstorage device than the data volume 300. For example, in FIG. 1 the datavolume 300 is stored on the storage device 125A, and the local CDP log302A is stored on the storage device 125B. Storing the local CDP log302A on a different storage device than the data volume 300 may providegreater protection for the data volume 300, e.g., in the event of afailure of the storage device 125A.

In addition to storing the block-level change information for the datavolume 300 in the local CDP log 302A, the volume management and backupsoftware 205 may also transmit the change information (e.g., the blockdata and timestamp) to a server computer system 90 which is coupled tothe local host computer system 82 through a network 84. In someembodiments the server computer system 90 may be coupled to the localhost computer system 82 through the Internet, and the change informationmay be transmitted over the Internet.

Thus, for each change that occurs to a block in the data volume 300, thevolume management and backup software 205 may store the new block dataand the timestamp information in the local CDP log 302A, and may alsotransmit the new block data and timestamp information over the Internetto the server computer system 90. The server computer system 90 mayexecute remote storage software 210 operable to store the new block dataand timestamp information in a remote CDP log 302B. For example, theremote CDP log 302B may be stored on one or more storage devicesincluded in or coupled to the server computer system 90, such as thestorage device 125C.

FIG. 2 is a flowchart diagram illustrating one embodiment of a methodfor writing to the data volume 300. The method of FIG. 2 may beimplemented by the volume management and backup software 205 executingon the local host computer system 82. As indicated in block 401, thevolume management and backup software 205 may receive a write request towrite a particular block of the data volume 300. For example, the volumemanagement and backup software 205 may receive the request from a clientapplication program executing on the local host computer system 82. Asindicated in block 403, the volume management and backup software 205may store the particular block in the data volume 300.

The volume management and backup software 205 may also store theparticular block and timestamp information in the local CDP log 302A forthe data volume 300, as indicated in block 405. In some embodiments theparticular block and the timestamp information may be stored in thelocal CDP log 302A synchronously with respect to storing the particularblock in the data volume 300. For example, in some embodiments, in orderfor the volume management and backup software 205 to return anindication to the client application that the write request wascompleted, the volume management and backup software 205 may wait untilboth the particular block has been successfully stored in the datavolume 300, and also successfully stored in the local CDP log 302A alongwith the timestamp information.

In other embodiments the particular block and the timestamp informationmay be stored in the local CDP log 302A asynchronously with respect tostoring the particular block in the data volume 300. For example, insome embodiments, the volume management and backup software 205 mayreturn an indication to the client application that the write requestwas completed as soon as determining that the particular block has beensuccessfully stored in the data volume 300, but without necessarilywaiting until the particular block has also been stored in the local CDPlog 302A. Instead, a write request to store the particular block and thetimestamp information in the local CDP log 302A may be performedasynchronously. However, the write request to store the information inthe local CDP log 302A is preferably performed in real time in responseto receiving the original write request from the client application,e.g., in order to provide continuous data protection for the data volume300. For example, the write operation to update the local CDP log 302Amay be performed in parallel with or immediately after the writeoperation to update the data volume 300. For example, one process of thevolume management and backup software 205 may place the block data andtimestamp information in a queue. Another process of the volumemanagement and backup software 205 may execute in parallel with or in amultitasking fashion with respect to the first process, and maycontinuously check for information in the queue that needs to be writteninto the local CDP log 302A.

As indicated in block 407, the volume management and backup software 205may also transmit the particular block and the timestamp informationover the Internet for storage in the remote CDP log 302B on the servercomputer system 90. The server computer system 90 may execute remotestorage software 210 operable to receive the particular block and thetimestamp information and store them in the remote CDP log 302B.

In some embodiments the local host computer system 82 may encrypt thedata before sending it to the server computer system 90. In someembodiments, only the block data may be encrypted so that the servercomputer system 90 can still read the timestamp information. Thus, atleast some of the data received from the local host computer system 82may be stored on the server computer system 90 in the encrypted form andsubsequently returned to the local host computer system 82 in theencrypted form (if the local host computer system 82 subsequentlyrequests to read the data, as discussed below). In other embodiments thelocal host computer system 82 may send unencrypted data to the servercomputer system 90, and the server computer system 90 may encrypt thedata before storing it. If the local host computer system 82subsequently requests the data to be returned, the server computersystem 90 may retrieve the data and decrypt it before returning it tothe local host computer system 82.

In some embodiments the volume management and backup software 205 mayalso transmit other information to the server computer system 90 inaddition to the particular block and the timestamp information. Forexample, the volume management and backup software 205 may also transmitidentification information and authentication information foridentifying the local host computer system 82 (or a user of the localhost computer system 82) to the server computer system 90 andauthenticating the information to be stored on the server computersystem 90. As another example, an ID or other information identifyingthe data volume 300 may be transmitted to the server computer system 90.For example, the server computer system 90 may be configured to provideremote storage services for storing CDP data for different data volumeson different local host computers. Thus, the server computer system 90may maintain a respective remote CDP log for each of the data volumesand may use the identification information and authenticationinformation received from the local host computer 82 to determine theappropriate remote CDP log in which to store the particular block andthe timestamp information transmitted in block 407.

In some embodiments the local host computer system 82 may digitally signthe data before sending it to the server computer system 90, e.g., usingthe private encryption key of a public/private encryption key pair. Thelocal host computer system 82 may provide the corresponding public keyto the server computer system 90 so that the server computer system 90can use it to authenticate the data and verify that it originated fromthe local host computer system 82. Similarly, the server computer system90 may provide the local host computer system 82 with the public key ofits own public/private encryption key pair, which the local hostcomputer system 82 can use to authenticate data received from the servercomputer system 90.

In various embodiments the timing of the network transmission operationindicated in block 407 may occur in various ways with respect to thetiming of the storage operations indicated in blocks 403 and 405. Asdescribed above, the storage of the change information in the local CDPlog 302A may occur either synchronously or asynchronously with respectto changing the data volume 300, and preferably occurs in a continuousmanner, e.g., such that change information for a particular block isstored in the local CDP log 302A in real time in response to receiving awrite request from the client application to write to the particularblock. In some embodiments the transmission of the change information tothe server computer system 90 may also occur in a real-time orcontinuous manner with respect to changing the data volume 300. Thetransmission of the change information to the server computer system 90may occur either synchronously or asynchronously with respect tochanging the data volume 300, and may also occur either synchronously orasynchronously with respect to storing the change information in thelocal CDP log 302A.

In particular, in some embodiments the change information may betransmitted to the server computer system 90 synchronously with respectto the storing the change information in the local CDP log 302A. Forexample, the storing of the change information in the local CDP log 302Aand the transmission of the change information to the server computersystem 90 may be considered as a synchronized or compound operation suchthat both of these operations must complete before the compoundoperation completes. For example, while one process is storing thechange information in the local CDP log 302A, another process mayexecute in parallel with or in a multitasking fashion with respect tothe first process to transmit the change information to the servercomputer system 90. The first process may complete the storing of thechange information in the local CDP log 302A first, but the volumemanagement and backup software 205 may wait until receiving anacknowledgement message from the server computer system 90 indicatingthat the change information was received before indicating completion ofthe compound operation. In some embodiments this compound operation mayalso be performed synchronously with respect to updating the particularblock in the data volume 300, or in other embodiments may be performedasynchronously, similarly as described above.

In other embodiments the change information may be transmitted to theserver computer system 90 asynchronously with respect to storing thechange information in the local CDP log 302A, where the changeinformation is stored in the local CDP log 302A either synchronously orasynchronously with respect to updating the particular block in the datavolume 300. For example, in some embodiments, when a first process ofthe volume management and backup software 205 receives the request fromthe client application to write the particular data block, the firstprocess may write the particular block to the data volume 300 and mayalso place the particular block and the timestamp information in twoqueues. A second process may asynchronously read the particular blockand the timestamp information from one of the queues and write them tothe local CDP log 302A. A third process may asynchronously read theparticular block and the timestamp information from the other queue andtransmit them to the server computer system 90 for storage in the remoteCDP log 302B. Thus, the storing of the change information (i.e., theblock data and the timestamp information) in the local CDP log 302A andthe transmission of the change information to the server computer system90 may occur asynchronously both with respect to each other and withrespect to the storing of the particular block in the data volume 300.However, these operations may still occur in a continuous manner, e.g.,in real time in response to receiving the write request from the clientapplication. For example, the second process and the third process mayboth execute to continuously check for new items to process in theirrespective queues, or may be immediately notified when new items areplaced in their respective queues.

In other embodiments the block data and timestamp information may not betransmitted to the server computer system 90 in real time in response toeach write request received from the client application, but may insteadbe transmitted on a periodic basis. For example, in some embodiments,change information may be transmitted to the server computer system 90at timed intervals. At each time interval, the change information forall of the blocks that have changed since the previous transmission maybe transmitted to the server computer system 90. Thus, in someembodiments, change information may be periodically transmitted to theserver computer system 90. In some embodiments this may be implementedby periodically creating incremental snapshots of the CDP log 302B andtransmitting the incremental snapshots to the server computer system 90.In various embodiments the volume management and backup software 205 mayperiodically transmit change information to the server computer system90 according to any desired time schedule, e.g., once per second, onceper minute, once per hour, etc.

As described above, change information specifying each block update andthe timestamp information for the update may be stored in the local CDPlog 302A on the host computer system 82A, and may also be transmitted tothe server computer system 90 for storage in the remote CDP log 302B.Thus, in some embodiments the remote CDP log 302B on the server computersystem 90 may contain the same information as the local CDP log 302A onthe local host computer system 82, e.g., the remote CDP log 302B mayeffectively be a copy of the local CDP log 302A. However, in otherembodiments the remote CDP log 302B may store more information regardingthe changes that have occurred to the data volume 300 than is stored inthe local CDP log 302A. For example, in some embodiments the local CDPlog 302A on the local host computer system 82 may be limited to aparticular maximum size, e.g., due to limited storage capacity of thestorage device(s) 125B on which the local CDP log 302A is stored. Aschange information accumulates in the local CDP log 302A, the local CDPlog 302A may approach its maximum possible size. Thus, it may sometimesbe necessary or desirable to delete some of the change information fromthe local CDP log 302A. In various embodiments, any desired criteria,heuristic, or algorithm may be used to select the change information tobe deleted. As one example, older change information may be purged fromthe local CDP log 302A, and newer change information may be retained.

Whereas the storage capacity of the local host computer system 82 may berelatively limited, the server computer system 90 may have much morestorage capacity. The server computer system 90 may, for example, bespecifically designed to store a large amount of data received fromvarious local host computer systems, e.g., to provide a remote backupservice for the local host computer systems. For example, the servercomputer system 90 may maintain a pool of storage devices, each having avery large storage capacity. Thus, in a typical embodiment, the servercomputer system 90 may be able to store all of the data received fromthe local host computer system 82 in the remote CDP log 302B on one ormore storage devices coupled to the server computer system 90, withoutneeding to purge any of the data from the remote CDP log 302B even if itbecomes very large. Thus, in a typical embodiment the remote CDP log302B may either contain the same data as the local CDP log 302A, or maycontain a superset of the data in the local CDP log 302A, e.g., the samedata as the local CDP log 302A plus additional data.

Referring now to FIG. 3, a flowchart diagram illustrating one embodimentof a method for reading from the data volume 300 is shown. The method ofFIG. 3 may be implemented by the volume management and backup software205 executing on the local host computer system 82. As indicated inblock 421, the volume management and backup software 205 may receive aread request to read a particular block of the data volume 300. Forexample, the volume management and backup software 205 may receive theread request from a client application program executing on the localhost computer system 82. In response, the volume management and backupsoftware 205 may attempt to read the particular block from the datavolume 300, as indicated in block 423.

Under normal circumstances, the block will be found in the data volume300, and the volume management and backup software 205 then returns thedata for the particular block to the client application, as indicated inblocks 425 and 427. However, in some cases the block may not be presentin the data volume 300. For example, a failure may have previouslyoccurred in which the data in the data volume 300 was lost.

If the block is not found in the data volume 300 then the volumemanagement and backup software 205 may attempt to read the particularblock from the local CDP log 302A, as indicated in 429. If theparticular block is found in the local CDP log 302A then the volumemanagement and backup software 205 returns the data for the particularblock to the client application, as indicated in blocks 431 and 433. Insome embodiments the volume management and backup software 205 may alsostore the data for the particular block in the data volume 300 so that asubsequent request for the same block can be satisfied by reading theblock from the data volume 300 without needing to read the block fromthe local CDP log 302A again.

However, in some situations the particular block may not be present inthe local CDP log 302A either. For example, the local CDP log 302A mayhave been lost in a failure in addition to the data volume 300 beinglost. As another example, some of the blocks may have previously beendeleted from the local CDP log 302A in order to save storage space,similarly as discussed above.

If the particular block is not found in the local CDP log 302A then thevolume management and backup software 205 may send a request for theparticular block over the Internet to the server computer system 90, asindicated in block 435. In response to the request the server computersystem 90 may read the particular block from the remote CDP log 302B andtransmit the block data to the local host computer system 82. The volumemanagement and backup software 205 on the local host computer system 82may receive the data for the particular block from the server computersystem 90 and return the data to the client application, as indicated inblocks 437 and 439. In some embodiments the volume management and backupsoftware 205 may also store the block data in the data volume 300, andpossibly the local CDP log 302A as well. (The server computer system 90may also transmit the timestamp information for the block along with theblock data so that the timestamp information can be stored in the localCDP log 302A in association with the block data.)

Thus, in the event of a failure in which both the data volume 300 andthe local CDP log 302A are lost, the data volume 300 can be restored byrequesting its blocks from the remote computer server 90. In thismanner, the Internet may effectively be treated as a virtual storagedevice by directing read requests for particular blocks of the datavolume 300 to the remote computer server 90 on the Internet. In variousembodiments this may be advantageous because the blocks of the datavolume 300 are replicated remotely in the remote CDP log 302B on theserver computer system 90, which may provide increased data protectionand redundancy for the data volume 300.

In various embodiments the system described above may also beadvantageous because the client applications that use the data volume300 may not have to wait for a restore operation to perform a fullrestore of the data volume 300 after a failure of the data volume 300and the local CDP log 302A have occurred. For example, even after thefailure has occurred the client applications may continue to send readrequests for blocks of the data volume 300 to the volume management andbackup software 205. The volume management and backup software 205 maysatisfy the read requests in real time by retrieving the specifiedblocks of the data volume 300 from the server computer system 90. Aseach block is retrieved, the block may also be stored in a new versionof the data volume 300 in order to gradually rebuild the data volume300. (In parallel with the client applications, the local host computersystem 82 may also execute restore software to restore all of the datato the new version of the data volume 300 by retrieving all the blocksof the data volume 300 from the server computer system 90.) Thus, theclient applications may experience a slight delay due to the networklatency involved in transmitting the blocks over the Internet, but theremay not be significant downtime due to total unavailability of the datavolume.

In addition, the system may provide for greater flexibility in restoringthe data volume 300 to previous points in time. For example, whereas thestorage space available locally on the local host computer system 82 maybe relatively limited, the server computer system 90 may effectivelyserve as a virtual storage device with a greater amount of availablestorage space. As discussed above, this may allow greater amounts ofchange data for the data volume 300 to be stored in the remote CDP log302B than can be stored in the local CDP log 302A. Thus, for example,the system may enable the data volume 300 to be restored to time pointsfor which corresponding block information is no longer available in thelocal CDP log 302A, e.g., due to having been purged to save storagespace.

FIG. 4 illustrates an embodiment in which the system includes a firstlocal host computer system 82A and a second local host computer system82B. The second local host computer system 82B may be located in adifferent geographic location than the first local host computer system82A, e.g., in different data centers, different cities, or evendifferent countries.

The local host computer system 82A may operate to write data to a firstcopy 300A of a data volume. Similarly as described above, each writerequest to write a particular block of the data volume 300A may causethe block to be updated in the data volume 300A itself, as well as acopy of the block and timestamp information being stored in the localCDP log 302A on the local host computer system 82A and in the remote CDPlog 302B on the server computer system 90.

Suppose now that it is necessary or desirable to restore the data volume300A to the local host computer system 82B or create a copy of the datavolume 300A on the local host computer system 82B. The local hostcomputer system 82B may execute restore software which first creates anempty copy 300B of the data volume and an empty local CDP log 302C onthe local host computer system 82B. The restore software may thenrequest all of the blocks for the data volume from volume management andbackup software 205 executing on the local host computer system 82B.Since the requested blocks are not yet present in either the copy 300Bof the data volume or the local CDP log 302C, the volume management andbackup software 205 may retrieve the blocks from the server computersystem 90 via the Internet, similarly as described above.

Thus, in some embodiments the system may enable a copy of a data volumeoriginally created and stored on one local host computer system to becreated on virtually any other local host computer system in the worldwith Internet access. The local host computer system on which it isdesired to create the copy of the data volume simply needs to executethe volume management and backup software 205 which communicates withthe server computer system 90 through the Internet in order to requestthe blocks of the data volume.

In addition to creating a copy of the data volume as it exists in itsmost recent state, in some embodiments the system may also be used torestore the data volume as it existed at previous points in time to thelocal host computer system 82B in FIG. 4. This may be useful, forexample, for data mining purposes. For example, it may be desirable toperform data mining in order to analyze the volume data as it existed ata particular time in the previous week. Thus, a user of the local hostcomputer system 82B may simply input the desired time point to a datamining application executing on the local host computer system 82B. Thedata mining application may then request the blocks of the volume fromthe volume management and backup software 205 on the local host computersystem 82B, e.g., where the read requests include the time informationspecified by the user. After finding that the blocks are not availablelocally, the volume management and backup software 205 may request theblocks from the server computer system 90, passing along the timeinformation specified by the user. The remote storage software 210executing on the server computer system 90 may use the specified timeinformation to retrieve the appropriate copy of each block of the volumefrom the remote CDP log 302B, e.g., whichever copy represents the stateof the block as it existed at the specified time.

In various embodiments, the local host computer system 82 and the servercomputer system 90 described herein may each include any type ofcomputing devices or other hardware devices. FIG. 5 illustrates anexample of the local host computer system 82 according to oneembodiment. In this example, the local host computer system 82 includesa processor 120 coupled to memory 122. In some embodiments, the memory122 may include one or more forms of random access memory (RAM) such asdynamic RAM (DRAM) or synchronous DRAM (SDRAM). However, in otherembodiments, the memory 122 may include any other type of memory insteador in addition.

The memory 122 may be configured to store program instructions and/ordata. In particular, the memory 122 may store the volume management andbackup software 205. The volume management and backup software 205 maybe executable by the processor 120 to perform the functions describedabove. The memory 122 may also store other software which operates inconjunction with or which is used by the volume management and backupsoftware 205, such as operating system software, file system software,network communication software, device management software, clientapplication software, etc.

In various embodiments the volume management and backup software 205 maybe implemented in any of various ways and may have any desired softwarearchitecture. For example, in some embodiments the volume management andbackup software 205 may be implemented as a single software program. Inother embodiments the volume management and backup software 205 may beimplemented as two or more software programs or modules that operate inconjunction with each other. For example, in some embodiments variousfunctions described herein may be implemented by different modules. Forexample, in some embodiments the volume management and backup software205 may include a first module operable to perform the functionsassociated with reading blocks from and writing blocks to the datavolume 300; a second module operable to perform the functions associatedwith reading information and writing information to the local CDP log302A; and a third module operable to perform the functions associatedwith transmitting information to and receiving information from theserver computer system 90.

Referring again to FIG. 5, it is noted that the processor 120 isrepresentative of any type of processor. For example, in someembodiments, the processor 120 may be compatible with the x86architecture, while in other embodiments the processor 120 may becompatible with the SPARC™ family of processors. Also, in someembodiments the local host computer system 82 may include multipleprocessors 120.

The local host computer system 82 may also include or may be coupled toone or more storage devices 125 on which the data volume 300 and thelocal CDP log 302A are stored. In various embodiments the storagedevices 125 may include any of various kinds of storage devices, such asdisk drive devices, optical storage devices, tape storage devices, flashmemory storage devices, etc. In one embodiment, the storage devices 125may include one or more disk drives configured as a disk storage system.In one embodiment, the disk storage system may be an example of aredundant array of inexpensive disks (RAID) system. In anotherembodiment, the disk storage system may be a disk array, or Just a BunchOf Disks (JBOD) (used to refer to disks that are not configuredaccording to RAID). In yet other embodiments, the storage devices 125may include RAM disks, for example.

In various embodiments the one or more storage devices 125 may becoupled to the local host computer system 82 in any of various ways,such as direct attached storage, fiber channel storage, storage areanetwork (SAN) storage, iSCSI storage, etc. In some embodiments the localhost computer system 82 may communicate with the one or more storagedevices 125 through a network.

The local host computer system 82 may also include one or more inputdevices 126 for receiving user input from a user of the local hostcomputer system 82. The input device(s) 126 may include any of varioustypes of input devices, such as keyboards, keypads, microphones, orpointing devices (e.g., a mouse or trackball). The local host computersystem 82 may also include one or more output devices 128 for displayingoutput to the user. The output device(s) 128 may include any of varioustypes of output devices or display devices, such as LCD screens ormonitors, CRT monitors, etc.

The local host computer system 82 may also include network connectionhardware 129 through which the local host computer system 82 connects tothe network 84, e.g., in order to transmit information to and receiveinformation from the server computer system 90. The network connectionhardware 129 may include any type of hardware for coupling the localhost computer system 82 to the network, e.g., depending on the type ofnetwork. In various embodiments, the local host computer system 82 mayconnect to the server computer system 90 through any type of network orcombination of networks. For example, the network may include any typeor combination of local area network (LAN), a wide area network (WAN),wireless networks, an Intranet, the Internet, etc. Examples of localarea networks include Ethernet networks, Fiber Distributed DataInterface (FDDI) networks, and token ring networks. Also, the local hostcomputer system 82 and the server computer system 90 may each be coupledto the network using any type of wired or wireless connection medium.For example, wired mediums may include Ethernet, fiber channel, a modemconnected to plain old telephone service (POTS), etc. Wirelessconnection mediums may include a wireless connection using a wirelesscommunication protocol such as IEEE 802.11 (wireless Ethernet), a modemlink through a cellular service, a satellite link, etc.

FIG. 6 illustrates an example of the server computer system 90 accordingto one embodiment. The server computer system 90 may include similarcomponents as those described above with reference to FIG. 5. However,in this case the memory 122 stores remote storage software 210. Theremote storage software 210 is executable by the processor(s) 120 toperform various functions described above with reference to the servercomputer system 90, such as writing information to and readinginformation from the remote CDP log 302B in response to requests fromthe local host computer system 82. The memory 122 may also store othersoftware which operates in conjunction with or which is used by theremote storage software 210, such as operating system software, filesystem software, network communication software, device managementsoftware, etc.

In various embodiments the remote storage software 210 may beimplemented in any of various ways and may have any desired softwarearchitecture. For example, in some embodiments the remote storagesoftware 210 may be implemented as a single software program. In otherembodiments the remote storage software 210 may be implemented as two ormore software programs that operate in conjunction with each other.

The remote CDP log 302B may be stored on one or more storage devices 125included in or coupled to the server computer system 90. Similarly asdescribed above, the storage devices 125 may include any of variouskinds of storage devices, such as disk drive devices, optical storagedevices, tape storage devices, flash memory storage devices, etc. Insome embodiments the server computer system 90 may communicate with theone or more storage devices on which the remote CDP log 302B is storedthrough a network.

It is noted that various embodiments may further include receiving,sending or storing instructions and/or data implemented in accordancewith the foregoing description upon a computer-accessible storagemedium. Generally speaking, a computer-accessible storage medium mayinclude any storage media accessible by one or more computers (orprocessors) during use to provide instructions and/or data to thecomputer(s). For example, a computer-accessible storage medium mayinclude storage media such as magnetic or optical media, e.g., one ormore disks (fixed or removable), tape, CD-ROM, DVD-ROM, CD-R, CD-RW,DVD-R, DVD-RW, etc. Storage media may further include volatile ornon-volatile memory media such as RAM (e.g. synchronous dynamic RAM(SDRAM), Rambus DRAM (RDRAM), static RAM (SRAM), etc.), ROM, Flashmemory, non-volatile memory (e.g. Flash memory) accessible via aperipheral interface such as the Universal Serial Bus (USB) interface,etc. In some embodiments the computer(s) may access the storage mediavia a communication means such as a network and/or a wireless link.

Although the embodiments above have been described in considerabledetail, numerous variations and modifications will become apparent tothose skilled in the art once the above disclosure is fully appreciated.It is intended that the following claims be interpreted to embrace allsuch variations and modifications.

1. A tangible, non-transitory computer-accessible storage medium storingprogram instructions executable to: in response to a first request toread a particular block of a data volume, attempt to read the particularblock from the data volume; in response to determining that theparticular block is not present in the data volume, attempt to read theparticular block from a first continuous data protection (CDP) log forthe data volume; in response to determining that the particular block isnot present in the first CDP log, send a second request for theparticular block over a network to a server computer system; and receivethe particular block from the server computer system.
 2. The tangible,non-transitory computer-accessible storage medium of claim 1, whereinthe program instructions are executable by a first computer system,wherein the server computer system is coupled to the first computersystem via the Internet; wherein sending the second request for theparticular block comprises sending the second request over the Internetto the server computer system.
 3. The tangible, non-transitorycomputer-accessible storage medium of claim 1, wherein the first requestspecifies a time; wherein the first request comprises a first requestfor data of the particular block as the particular block existed in thedata volume at the specified time; wherein the second request includesthe specified time; wherein the second request comprises a secondrequest for the data of the particular block as the particular blockexisted in the data volume at the specified time; and wherein receivingthe particular block comprises receiving the data of the particularblock as the particular block existed in the data volume at thespecified time.
 4. The tangible, non-transitory computer-accessiblestorage medium of claim 1, wherein in response to a third request towrite the particular block to the data volume, the program instructionsare further executable to: store the particular block in the datavolume; store the particular block in the first CDP log for the datavolume; and transmit the particular block over the network for storageon the server computer system.
 5. The tangible, non-transitorycomputer-accessible storage medium of claim 4, wherein said transmittingthe particular block over the network for storage on the server computersystem is performed as a synchronous operation with respect to saidstoring the particular block in the first CDP log, such that the programinstructions are executable to wait for an acknowledgement to thetransmission before returning an indication that storing the particularblock in the first CDP log was completed.
 6. The tangible,non-transitory computer-accessible storage medium of claim 4, whereinsaid transmitting the particular block over the network for storage onthe server computer system is performed as an asynchronous operationwith respect to said storing the particular block in the first CDP log,such that the program instructions are executable to return anindication that storing the particular block in the first CDP log wascompleted without waiting for an acknowledgement to the transmission. 7.A computer-implemented method comprising: in response to a first requestto read a particular block of a data volume, a first computer systemattempting to read the particular block from the data volume; inresponse to determining that the particular block is not present in thedata volume, the first computer system attempting to read the particularblock from a first continuous data protection (CDP) log for the datavolume; in response to determining that the particular block is notpresent in the first CDP log, the first computer system sending a secondrequest for the particular block over a network to a server computersystem; and the first computer system receiving the particular blockfrom the server computer system.
 8. The computer-implemented method ofclaim 7, wherein sending the second request for the particular blockcomprises, sending the second request over the Internet to the servercomputer system.
 9. The computer-implemented method of claim 7, whereinthe first request specifies a time; wherein the first request comprisesa first request for data of the particular block as the particular blockexisted in the data volume at the specified time; wherein the secondrequest includes the specified time; wherein the second requestcomprises a second request for the data of the particular block as theparticular block existed in the data volume at the specified time; andwherein receiving the particular block comprises receiving the data ofthe particular block as the particular block existed in the data volumeat the specified time.
 10. The computer-implemented method of claim 7,further comprising: the first computer system receiving a third requestto write the particular block to the data volume; in response to thethird request: storing the particular block in the data volume; storingthe particular block in the first CDP log for the data volume; andtransmitting the particular block over the network for storage on theserver computer system.
 11. The computer-implemented method of claim 10,wherein said transmitting the particular block over the network forstorage on the server computer system is performed as a synchronousoperation with respect to said storing the particular block in the firstCDP log by waiting for an acknowledgement to the transmission beforereturning an indication that storing the particular block in the firstCDP log was completed.
 12. The computer-implemented method of claim 10,wherein said transmitting the particular block over the network forstorage on the server computer system is performed as an asynchronousoperation with respect to said storing the particular block in the firstCDP log by returning an indication that storing the particular block inthe first CDP log was completed without waiting for an acknowledgementto the transmission.
 13. A system comprising: a first computer systemconfigured to: receive a write request to write a particular block to adata volume; in response to the write request: store the particularblock in a first copy of the data volume; store the particular block ina first continuous data protection (CDP) log for the first copy of thedata volume; transmit the particular block over a network for storage ona server computer system; and a second computer system configured to: inresponse to a read request to read the particular block of the datavolume, attempt to read the particular block from a second copy of thedata volume; in response to determining that the particular block is notpresent in the second copy of the data volume, attempt to read theparticular block from a second CDP log for the second copy of the datavolume; in response to determining that the particular block is notpresent in the second CDP log, send a request for the particular blockto the server computer system; receive the particular block from theserver computer system.
 14. The system of claim 13, wherein the firstcomputer system is coupled to the server computer system via theInternet; wherein transmitting the particular block for storage on theserver computer system comprises the first computer system transmittingthe particular block over the Internet to the server computer system;wherein the second computer system is coupled to the server computersystem via the Internet; wherein sending the request for the particularblock to the server computer system comprises the second computer systemsending the request for the particular block over the Internet to theserver computer system.
 15. The system of claim 13, wherein, in responseto the write request, the first computer system is further configuredto: determine a current time; and store timestamp information specifyingthe time in the first CDP log in association with the particular block;and transmit the timestamp information over the network for storage onthe server computer system in association with the particular block.